What is Object-Oriented Programming?

Many programming languages, such as C++, Java, and Smalltalk, are object-oriented. What does this mean, and why bother with it? This article explores the meaning and purpose of object-oriented programming.

Abstraction, which means hiding irrelevant details, is a central theme in Computer Science. For example, suppose you are writing a program and frequently need to calculate how far you travel at a constant acceleration given an initial speed and an amount of time elapsed. The formula is: 0.5*accel*time^2 + initSpeed*time. But you don't want to remember this formula every time you need to use it; you'd much rather put it in a function:

	function displace(accel, initSpeed, time)
		displace = 0.5*accel*time^2 + initSpeed*time
	end function

This function is an abstraction: now you can just use it knowing what it does, but not needing to remember the details of how it works.

Programming languages are abstractions because they allow us to tell a computer what to do without worrying about how the computer does it (the irrelevent details.) Programming may seem difficult at times. However, it's far better than trying to write code in machine language, which just consists of 0's and 1's, which are unimportant to the essense of what you want the computer to do. Even the machine language your computer understands is an abstraction. Your computer consists of incredibly complex electronic circuits, and how these circuits work is irrelevant to the ultimate goals a programmer has. The circuits are also just an abstraction for electrons zipping around, responding to forces. Physicists can debate about whether electrons are an abstraction. Programming is just a huge tower of abstractions designed to make computing intuitive for humans.

So what has object-oriented programming got to do with this? It is just another layer of abstraction, one that attempts to make programming even more convenient for humans. Suppose you want to write a program to simulate traffic. You will need some way to represent a car. In Liberty BASIC, you could try to use a numeric variable for this purpose. For example:

	car1 = 5

Clearly, this is just not sufficient to represent a car, which has many attributes. Similarly, a string variable just isn't going to be good enough. What we need is to create our own type of variable that can store many attributes, i.e. something like this:

	type car:
		model$
		color$
		year
		location
		speed
		accel
		curRadioStation
	end type

Now we could just create several variables of this new "type of variable". These are called objects and they will each represent a different car with all the attributes specified in the "car" type:

	myCar = new car
	neighborsCar = new car
	dadsTruck = new car

Note that this is not valid Liberty BASIC code; we are just exploring what a language with these features might be like. Now to manipulate the attributes of these "car objects" we've created, we might do something like this:

	myCar.color = "red"
	myCar.year = 1995
	dadsTruck.color = "green"
	dadsTruck.year = 2001

This is good - we've come up with something that's more human-like and less computer-like. This construction allows us to think more about cars and less about variables. The idea we've just discussed is available in many programming languages, and it's an important first step toward object-oriented programming. But we've got one big problem to deal with: we can now represent a car, but it can't "do" anything. If we want our car to accelerate, we have to do the calculations ourselves to figure our the speed of the car and where it ends up. We would really like our car object to do these things itself, so we won't have to worry about it. We would like to be able embed subroutines and functions right into our object:

	class car:
		model$
		color$
		year
		location
		speed
		accel
		curRadioStation

		method go(time)
			location = location + 0.5*accel*time^2 + speed*time
			speed = speed + accel*time
		end method
	end class

We're now adopting standard object-oriented jargon - saying "class" rather than "type of variable". Those variables (model, color, etc.) associated with an object are called "fields", and the subroutine we've embedded in the class is called a "method". But this terminology is irrelevant to the concepts we're discovering.

Notice that now the acceleration and initial speed information does not need to be passed into the "go" method; it is already available in the "speed" and "accel" fields. Also notice that in this case, the "go" method needn't return a value; the new location of the car is stored in the "location" field and can be accessed later if it is needed. We could add many more methods to add functionality and usefulness to our car class. Here is an example of how this class might be used:

	myCar = new car
	myCar.color$ = "red"
	myCar.accel = 4
	myCar.speed = 0
	
	myCar.go(3)
	print("After 3 seconds, my " + myCar.color$ + " car has gone this far:")
	print(myCar.location)

There is a good analogy to make between object-oriented programming and human language. You can think of a class as a noun; it represents a specific type of thing that is meaningful to humans (it needn't represent a material thing, though.) A field is like an adjective; it describes some attribute of the class it's in (a noun.) A method is like a verb; it is an action the class is capable of performing.

The idea of using a class to represent an object that has attributes (fields) and can do things (methods) is a useful abstraction applicable in many scenarios. In fact, the programming language Java insists that all executable code be placed in methods inside classes. The main goal of object-oriented programming is to allow more intuitive, human-oriented code to be written. Once a class is written, it can be used by other programmers who know what it does but who don't care about the details of how it works. Object-oriented programming serves only to make computing more convenient for humans - your computer couldn't care less whether or not the program it's running was written in an object-oriented language.

---